Products
In-IDE
IDE extension that lets you fix coding issues before they exist!
Discover SonarQube for IDE
SaaS
Setup is effortless and analysis is automatic for most languages
Discover SonarQube Cloud
Self-Hosted
Fast, accurate analysis; enterprise scalability
Discover SonarQube Server

Secrets
ABAP
Ansible
Apex
AzureResourceManager
C
C#
C++
CloudFormation
COBOL
CSS
Dart
Docker
Flex
GitHub Actions
Go
HTML
Java
JavaScript
JSON
JCL
Kotlin
Kubernetes
Objective C
PHP
PL/I
PL/SQL
Python
RPG
Ruby
Rust
Scala
Shell
Swift
Terraform
Text
TypeScript
T-SQL
VB.NET
VB6
XML
YAML

Kotlin static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your KOTLIN code

Tags

Impact

Clean code attribute

Core plugins IDs should be replaced by their shortcuts
Code Smell
Gradle settings file should always be present
Code Smell
Dependencies should be grouped by destination
Code Smell
Tasks should define "description" and "group"
Code Smell
"rootProject.name" should always be present in Gradle settings
Code Smell
Dependency versions shouldn't be hard-coded
Code Smell
"tasks.register()" should be preferred over "tasks.create()"
Code Smell
Null checks should be useful
Code Smell
Variables assigned values should be read
Code Smell
"It" shouldn't be used as a lambda parameter name
Code Smell
Check for preconditions should be simplified
Code Smell
Redundant type casts should be removed
Code Smell
Type casts and type checks that can never succeed should be removed
Code Smell
Expression should be simplified with "isEmpty", "isNotEmpty" or "isNullOrEmpty"
Code Smell
"find" should be replaced with "any", "none" or "contains"
Code Smell
Function chain using "filter" should be simplified
Code Smell
Abstract class should be interface
Code Smell
Collection should be immutable if contents is not changed
Code Smell
Structural equality tests should use "==" or "!="
Code Smell
Element access should use indexed access operators
Code Smell
Single function interfaces should be functional interfaces
Code Smell
Functional interface implementations should use lambda expressions
Code Smell
Singleton pattern should use object declarations or expressions
Code Smell
Delegator pattern should use "by" clause
Code Smell
Getter and setter pattern should use property getters and setters
Code Smell
"when" statements should be used instead of chained "if" statements
Code Smell
"return" statements should be lifted before "if" or "when" statement
Code Smell
"Unit" should be used instead of "Void"
Code Smell
"suspend" modifier should not be redundant
Code Smell
Kotlin coroutines API for timeouts should be used
Code Smell
The return value of functions returning "Deferred" should be used
Code Smell
ViewModel classes should create coroutines
Code Smell
Extension functions on CoroutineScopes should not be declared as "suspend"
Code Smell
Suspending functions should not be called on a different dispatcher
Code Smell
Dispatchers should be injectable
Code Smell
Functions returning Flow/Channel should not be suspending
Code Smell
Suspending functions should be main-safe
Code Smell
Coroutine usage should adhere to structured concurrency principles
Code Smell
"MutableStateFlow" and "MutableSharedFlow" should not be exposed
Code Smell
Redundant methods should be avoided in data classes
Code Smell
Operator "is" should be used instead of "isInstance()"
Code Smell
Character classes in regular expressions should not contain the same character twice
Code Smell
Unicode-aware versions of character classes should be preferred
Code Smell
Character classes should be preferred over reluctant quantifiers in regular expressions
Code Smell
Empty lines should not be tested with regex MULTILINE flag
Code Smell
Regular expressions should not be too complicated
Code Smell
Lambdas should not have too many lines
Code Smell
Native features should be preferred to Guava
Code Smell
Multi-line comments should not be empty
Code Smell
Functions should not have identical implementations
Code Smell
Cognitive Complexity of functions should not be too high
Code Smell
"var" should be "val" if local variable is never re-assigned
Code Smell
Kotlin parser failure
Code Smell
Boolean checks should not be inverted
Code Smell
Code annotated as deprecated should not be used
Code Smell
Two branches in a conditional structure should not have exactly the same implementation
Code Smell
"when" statements should not be nested
Code Smell
Unused local variables should be removed
Code Smell
"when" statements should not have too many clauses
Code Smell
Track lack of copyright and license headers
Code Smell
Functions should not have too many lines of code
Code Smell
Control flow statements "if", "for", "while", "when" and "try" should not be nested too deeply
Code Smell
"if ... else if" constructs should end with "else" clauses
Code Smell
Sections of code should not be commented out
Code Smell
Statements should be on separate lines
Code Smell
String literals should not be duplicated
Code Smell
Functions should not be empty
Code Smell
Unused function parameters should be removed
Code Smell
Local variable and function parameter names should comply with a naming convention
Code Smell
"when" clauses should not have too many lines of code
Code Smell
Unused "private" methods should be removed
Code Smell
Track uses of "TODO" tags
Code Smell
Track uses of "FIXME" tags
Code Smell
Deprecated code should be removed
Code Smell
Unnecessary imports should be removed
Code Smell
Boolean literals should not be redundant
Code Smell
Redundant pairs of parentheses should be removed
Code Smell
Nested blocks of code should not be left empty
Code Smell
Functions should not have too many parameters
Code Smell
Expressions should not be too complex
Code Smell
Mergeable "if" statements should be combined
Code Smell
Tabulation characters should not be used
Code Smell
Files should not have too many lines of code
Code Smell
Lines should not be too long
Code Smell
Class names should comply with a naming convention
Code Smell
Function names should comply with a naming convention
Code Smell

Expression should be simplified with "isEmpty", "isNotEmpty" or "isNullOrEmpty"

intentionality - clear

maintainability

Code Smell

Why is this an issue?

How can I fix it?

More Info

The expression can be simplified using one of the functions isEmpty, isNotEmpty or isNullOrEmpty.

What is the potential impact?

Readability and Understanding

This change makes the code more concise and easier to understand. The additional comparison operator would increase the complexity of the expression while not offering any benefit. The function names isEmpty, isNotEmpty and isNullOrEmpty are descriptive on the other hand, so it is evident to readers what the purpose of the expression is.

Available In:

Catch issues on the fly,
in your IDE

Detect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories

Analyze code in your
on-premise CI

Available Since
10.1

Analyze code in your
on-premise CI

Developer Edition
Available Since
10.1

In-IDE

SaaS

Self-Hosted